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reviewed and evaluated. Specifically, it explores the 
advantages and difficulties of connecting Shipboard 
Non-tactical ADP Program (SNAP) systems to the Defense 
Data Network ( DDN ) . A review of existing information 
exchange procedures, including NTS, SNAP II, and DDN, 
is provided. An overview of the future Navy Data 
Communications Control Architecture (NDCCA) is 
presented along with an interim proposal to connect 
current and future architectures. An analysis of 
present Navy and commercial organizations using DDN- 
type applications such as File Transfer Protocol (FTP) 
and electronic mail is presented. 
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I. INTRODUCTION 



The world is becoming a more complex place. This 
results in an increased demand for information exchange 
capability. One area in which this is exhibited is the 
number of naval messages sent each day. Despite 
efforts to control the amount of naval message traffic 
this number continues to increase. 

A. THE PROBLEM 

The Navy is currently experiencing significant 
problems with information transfer and processing. 
Despite increasing demands for information handling the 
Navy is bound by: (1) the limited capacity of the 
Naval Telecommunications System (NTS) and (2) limited 
personnel resources. The impact of limited personnel 
becomes more critical each year as the availability of 
personnel is reduced due to budgetary and demographic 
constraints. Additionally, the complexities of today’s 
ships and weapons systems require more attention from 
our sailors. This effectively reduces the time 
available for processing messages, reports, publication 
and instruction changes, and the assorted 
administrative data which is currently demanded of 
them . 
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This thesis deals with the difficulties of non- 
tactical, unclassified information exchange. This 
includes direct mi ssion/ support information as well as 
the myriad of administrative reporting requirements 
essential to the maintenance of combat ready ships and 
crews . 

B. THE SOLUTION 

The solution to this problem is threefold. First, 
improvements in information processing efficiency must 
be achieved. Second, improvements in methods of 
information exchange itself are necessary. Third, the 
Navy must examine, and when appropriate implement, new 
alternatives for information processing and 
transmission . 

C . THE METHOD 

1 . SNAP-Current Action 

The Shipboard Non-tactical ADP Program (SNAP) 
serves as the cornerstone upon which today’s shipboard 
administrative functions are centered. SNAP is the 
focal point between the ship and shore based support 
activities. SNAP provides the capability to transmit 
and receive information via naval messages, magnetic 
tape, or electronically through the Defense Data 
Network ( DDN ) . The latter is currently being 
demonstrated on several test ships. Improvements to 
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the SNAP system will greatly aid in the solution to 
this information processing dilemma. 

2 . Long-range Action 

The Navy’s long-range effort to meet current 
and future demands is still in its infancy. A 
multilevel communications architecure , the Navy Data 
Communications Control Architecture (NDCCA), is being 
developed to handle all future communications 

requirements. This system has lower levels dedicated 
to providing afloat, base and long haul communications. 
Planned development and implementation of the NDCCA is 
scheduled for the mid-1990’s. 

3 . Interim Action 

In the interim, the Navy must provide a 
satisfactory method to handle its current demands. The 
solution must be able to provide communications between 
ships and shore commands, at-sea as well as inport. 
Provisions must allow for both the loss or restriction 
of normal communications channels and the ability to 
handle increasingly large volumes of data. 

D. ORGANIZATION 

This thesis is organized into eight chapters, each 
presenting background information or possible 
approaches to consider when developing solutions to 
this problem. Chapter II provides a discussion of the 
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organizational requirements mandating increased 
information processing. 

Chapter III reviews both the Naval 
Telecommunications System and current shipboard ADP 
capability. This provides the framework necessary for 
examining information exchange problems and potential 
solutions . 

Chapter IV reviews the Defense Data Network. This 
is the key ingredient in the solution to the 
information exchange problem. A quick overview of the 
DDN is presented as well as an examination of 
applications which are directly beneficial to ships. 

Chapter V provides a summary of current methods of 
information exchange. Additionally, a summary of the 
Navy Data Communications Control Architecture is 
presented. This elucidates long range Navy plans. 
Finally, an interim proposal is developed which 
provides for improved information exchange capability 
while maximizing utilization of present systems. 

Chapter VI reviews two systems currently employing 
the DDN as a method to exchange information. This 
demonstrates the feasibility of both the interim and 
long range solutions. 

Chapter VII presents an analysis of DDN 
applications for shipboard use and examines the 
inherent connectivity problems when dealing with ships. 
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Additionally, a discussion is presented concerning the 
difficulty of both educating and training naval 
personnel to maximize the potential of the SNAP system 
and its future telecommunications capability. 

The final chapter. Chapter VIII, presents the 
author's conclusions and recommendations. 
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I I . ORGANIZATIONAL REQUIREMENTS 



A. BACKGROUND 

Organizations may be viewed as information 
processing mechanisms. This is especially appropriate 
for large, complex organizations like the United States 
Navy. In such organizations, information serves as the 
dynamic glue that binds together the resources of 
people, capital and technology. [Ref. 1] It is 
critical that the mechanisms for processing this 
information operate as efficiently as possible to allow 
required information to move quickly and accurately 
throughout the organization. 

1 . Complex World 

The world in which the United States Navy 
operates today is much more complex and dynamic than 
even a decade ago. The range of a battle group’s 
sensors and weapons extend hundreds of miles. From the 
ocean’s depths, to space above, the Navy exists in a 
greatly expanded sphere. As with the range of the 
sensors, the speed and accuracy of weapons has also 
greatly improved. Mach-plus weapons are common and 
cruise missiles hit targets with an accuracy measured 
in feet after traveling distances measured in hundreds 
of miles. Satellites instantaneously provide 
information to the fleet which is limited only by the 
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imagination of designers and the desires of the 
operators. The up, down and out credo of the Navy’s 
surface warfare community serves to focus on the 
tremendously difficult and complex problems faced by 
today’s Navy. [Ref. 2] 

2 . Complexity Requires Slack 

It is important to realize that as the world 
becomes more complex there is a concurrent rise in 
uncertainty. The world can no longer be viewed as 
black and white, but tends to exist as multiple shades 
of grey. This increase in uncertainty requires that a 
greater amount of information must be processed in the 
same amount of time. Increased resources are required 
to process this information. Failure to provide these 
resources, essentially a failure to increase the amount 
of organizational slack, results in decreased 
performance levels. [Ref. 3] 

3 . Resulting Problems 

The degree of complexity in which the Navy 
exists encompasses all aspects of the organization. 
The Navy has responded to this requirement to expand 
its information processing capacity by increasing 
shipboard computers, both tactical and non-tactical , 
and greatly increasing its use of communications 
systems to disseminate this information. What is often 
overlooked is that the complexities of the weapon 
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systems and sensors, mentioned above, are directly 
related to the logistics, personnel and administrative 
functions necessary for their support. This thesis 
concentrates on the essential area of mission support. 
Much can be gained by streamlining procedures through 
automation and by providing systems which support 
efficiency and timeliness in accomplishing information 
exchange . 

The information processing requirements imposed 
on the operating forces at-sea have increased greatly 
in response to the demands of a more complex 
environment. This has resulted in two problems. 

a. Increased Workload for Fleet Personnel 

First, the workload of at-sea operating 
forces has dramatically increased in its attempt to 
provide required information to the system. The impact 
of the large amount time spent on recurring reports and 
messages has been viewed by the Secretary of the Navy 
as critical. Time spent on administrative matters 
directly reduces available training and maintenance 
time. This negatively impacts operational readiness. 

A flag level review in 1985, ordered by 
then Secretary of the Navy John Lehman, found that Navy 
and Marine aviators spent an average of two-thirds of 
their time performing administrative duties unrelated 
to their mission. It is the author’s experience that 
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this figure is even higher aboard Navy surface ships. 
In response to this finding, Secretary Lehman ordered 
reviews of the Navy’s reporting requirements in an 
effort to reduce the administrative burden on the 
operating forces. This was ultimately transformed into 
an order to reduce by fifty percent all administrative 
related reports and duties imposed by Secretary of the 
Navy ( SECNAV ) directives. [Ref. 4] Unfortunately, upon 
completion of the Navy’s chain of command review, only 
a negligible number of reports were eliminated which 
directly reduced the administrative burden on the 
operating forces. This is predictable following the 
premise that increasing complexity requires greater 
information exchange to maintain current performance 
levels . 

b. NTS Overload 



Second , 


this 


demand 


f or 


increasing 


information exchange 


has 


resul ted 


in a 


continuing 



growth in the amount of naval message traffic sent 
through the NTS. The NTS is limited by the number of 
satellite channels available. As a result, only a 
finite amount of information can be handled by the 
system. As the number of messages grow, system 
saturation occurs resulting in slower delivery of 
critical operational messages. 
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4 . Navy Action 



Historically, the Navy has segregated 
information into either textual message traffic or 
batch data. The Navy’s response to the above stated 
problems has centered in two separate areas. One area 
attempts to improve data handling and the other 
attempts to minimize the number of messages. 

a. Automat ion-SNAP 

The development and implementation of the 
shipboard SNAP I / I I systems are designed to provide 
automated handling of many administrative requirements. 
These include shipboard Maintenance and Material 
Management (3-M), supply and financial management 
functions, shipboard administrative management, file 
access and word processing. This automation improves 
efficiency and lowers error rates thereby reducing 
administrative time demands on personnel and increasing 
organizational slack. 

b. Message Constraints 

The Navy Telecommunications System has made 
a concerted effort to reduce the load on the message 
system by the establishment of message reduction 
systems. These efforts concentrate on the reduction or 
elimination of administrative message traffic. [Ref. 5] 

(1) Navgrams . The Navy Mailed Message 
Program (NAVGRAM) was developed as an alternate method 
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to naval messages. It allows an originator the 
simplicity of the naval message format, while actually 
transmitting the information through the postal system. 
This program was created to help reduce the number of 
messages sent over the NTS. 

( 2 ) Administrative Message Designation . 
The NTS also established the requirement that all 
administrative message traffic be designated as such by 
the addition of "ZYB" in the date-time-group line of 
the message. This allows the NTS to segregate 
administrative messages for delayed transmission when 
system saturation occurs. 

(3) Message and Report Reduction . The 
Navy’s message reduction program was established by the 
Chief of Naval Operations ( CNO ) in 1985 to produce a 
twenty percent message reduction in traffic. This, 
combined with the Secretary of the Navy’s report 
reduction program, demonstrates the Navy’s effort to 
reduce the administrative burden on Navy personnel. 

c. Evaluation of Current Actions 

This Navy action, described above, has not 
improved information exchange. While the introduction 
of SNAP has been a great asset to those ships with the 
system installed, the lack of a telecommunications 
package, or an alternate method for timely information 
transfer, has severely limited system effectiveness. 
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As a result, duplication of effort and excessive 
paperwork remains commonplace. The Navy’s attempt at 
message reduction also fails to satisfy information 
exchange demands. Message traffic reduction attacks 
only the short-term problem of system saturation. This 
may in fact be counter productive to the needs of the 
Navy as a whole. The demand for information is valid 
and this demand must be met. It is absolutely 
essential that the Navy realize that it cannot allow 
the present capacity of the system to restrict the 
amount of information transmitted. The Navy must 
ensure that system capacity be developed to handle all 
required information. Efforts must be directed in the 
area of improving information exchange, not in attempts 
to restrict this information flow. 

d. Solution Must Provide Slack 

The solution to this problem should include 
the following characteristics. One, it must provide 
for efficient, timely information exchange. Two, the 
demand upon shipboard personnel should be minimized. 
Specifically, information should be entered into a 
database once and easily retrieved upon demand as 
needed. Three, an effort must be made to minimize and 
reduce the impact on the NTS. These efforts include 
total message traffic reduction and impact minimization 
by using prioritization and queuing schemes. 
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It is important to realize that it is the 
increasing complexity of today’s environment that is 
driving this demand for increased information 
processing capability. Additional information must be 
exchanged throughout the organization or the Navy will 
see a decrease in its level of performance. The need 
to accommodate this information exchange requirement is 
exhibited in the increasing number of messages 
transmitted annually. This increase in volume is 
expected and necessary. The Navy should attempt to 
introduce methods to handle the increased demand, not 
to impose limits on information transfer. 
Specifically, attempts should be made to develop more 
efficient and capable methods to process the required 
information. A SNAP/DDN interface is a method to help 
meet these requirements which is examined in this 
thesis . 

Uncertainty is reduced by information, but 
information is costly. In the Navy, the users are 
operationally experienced commanders. They must decide 
whether to buy missiles or communications equipment. 
These users are in the best position to determine the 
degree to which information is worthwhile. It should, 
therefore, be required that support organizations like 
the Defense Communications Agency ( DCA ) and Naval 
Telecommunications Command (NTC) provide complete and 
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accurate costing information to allow operational 
commanders the data necessary to decide on the optimal 
information capacity to purchase. For the support 
communities to impose information constraints upon the 
operating forces, without inputs as to the value of 
information, is simply foolish. 

B. SYSTEM CONSTRAINTS 

In the evaluation of this problem several 
constraints must be addressed. 

1 . Department of Defense (POD) Long Haul Directive 
"The DDN will be used by all DOD ADP (Automatic 

Data Processing) systems and data networks requiring 
interconnection by telecommunications." [Ref. 6] This 
specifies the DDN as medium of long haul communications 
and requires that all data communications be compatible 
with the DDN. The DDN is the only long haul electronic 
medium allowed by current directives. 

2 . Shipboard Requirements 

There are specific shipboard unique 
specifications which must be adhered to. These include 
manpower and training limitations, equipment space and 
weight constraints, and cost and performance 
requirements. Specific applications must also be 
designed to meet the needs of the shipboard operators. 
This necessitates user friendly systems, ad hoc query 
capability, and structured programs for recurring. 
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formatted reports. Examples in this area include 3-M 
system reporting, supply processing, pay and personnel 
record keeping, and correspondence files. 

C. INFORMATION EXCHANGE REQUIREMENTS 
1 . Organizational Requirements 

Several key factors directly effect the amount 
of information exchanged within organizations. The 
impact of these factors on large organizations like the 
Navy is dramatic. The following factors each generate 
the need for increased information exchange: (1) 

increasing organizational size (2) increasing 

organizational interdependence (3) increased 

uncertainty caused by faster environmental changes and 
a higher degree of external environmental complexity 
(4) increasing time pressure (5) closer supervision, 
due to either actual requirements or the perceived 
need, which occurs naturally as an organization ages. 
[Ref. 7] 

This demand for higher levels of information 
exchange may be handled in several ways. The 
organization may simply handle messages at a slower 
rate. Screening procedures may be established at lower 
levels or the vertical hierarchy may be increased to 
distribute the information more evenly throughout the 
organization. The organization may be reconfigured 
into groups composed of similar functions. These 
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alternatives, however, will not allow the Navy to 
function at its required level of performance and are 
therefore unacceptable. A viable method which allows 
the Navy to satisfy this higher information demand is 
to improve communications efficiency. This includes 
improving the speed-of-service , developing better 
methods of presenting the information and increasing 
the reliability of the information thereby reducing 
uncertainty and providing more data when required. 
Essentially there is a need to create additional 
organizational slack. [Ref. 8] 

Organizations have several internal 
communications networks. There are formal, structured 
communications which are recognized as "official" and 
there are informal networks which provide for "non- 
official" communications. Formal communications 
channels generally match the formal authority 
structure. Informal communications are developed where 
necessary to meet needs not satisfied by the formal 
structure. Informal communications are often further 
divided into subformal and personal categories. 
Informal communications occur naturally, possessing a 
great capacity to create increased organizational slack 
by improving efficiency and effectiveness. Informal 
communications are much faster than formal 
communications. They provide a means to float "trial 
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balloons” and test the waters before going official. 
People are normally more open and honest when 
communicating unofficially. In general, informal 
communications provide a method to greatly increase an 
organization’s ability to process information and meet 
the need to develop increased slack. A goal of good 
management is to develop the organizational framework 
to maximize the potential of a well developed informal 
communications network. [Ref. 9] 

Electronic mail is extremely well suited to 
optimizing informal communications within 
organizations. Electronic mail is fast and easy. It 
is proving to be of great benefit to those 
organizations which implement it. Electronic mail is 
currently available for shipboard use on the SNAP 
system. A telecommunications connection between SNAP 
and the DDN would provide this capability throughout 
the Navy. This is quite feasible for ships inport. 
The inport, homeport advantages of this capability 
would be enormous. Rapid, informal messages between 
sister ships and squadron commanders would facilitate 
efficient and effective communication, benefitting all 
parties . 

2 . Commanding Officer’s Requirements 

Commanding Officers have demonstrated a 
requirement for recorded communications. Their 
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performance indicates a preference for message 
transmission over mail. The reasons lie in the 
advantageous characteristics which messages provide. 
First, from a command point of view, naval messages are 
faster and easier to prepare. Additionally, this 
preparation is less manpower intensive. Second, they 
provide the capability for multiple addressees with de 
facto receipt acknowledgement. This is a significant 
benefit to commands which must be able to demonstrate 
compliance of reporting requirements and to requests 
from seniors. Three, speed-of-service for naval 
messages is measured in hours as opposed to the days or 
weeks which may be lost using mail. Delays, which can 
occur due to inefficient routing at the receiving 
command, are generally minimized by message traffic. 
In many cases this time delay directly results in 
additional dollar expenditures. For example, time 
savings in parts procurement or contracting services 
often precludes expensive material expediting or 
costly, crisis mandated overtime. 

Electronic mail sent over the DDN provides the 
identical characteristics of the naval message without 
the necessity of increasing the demand on the NTS. In 
fact, this capability allows inport ships to transmit 
required information via electronic mail thus reducing 
the traffic volume on NTS. 
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III. CURRENT SYSTEMS 



A. NAVAL TELECOMMUNICATIONS SYSTEM 
1 . Increasing Message Demand 

The number of naval messages in the first half 
of the 1980’s increased at a rate of ten percent per 
year. This rapidly began to strain the capacity of 
the NTS and has the potential of crippling vital 
command and control functions. In 1985 the CNO 
initiated message reduction actions which lowered this 
increase to a one to two percent annual growth rate. 
While this improvement is significant, the increase 
continues to consume valuable satellite channel 
bandwidth. [Ref. 10] 

The NTS was designed to provide command, 
control and intelligence communications capability 
between afloat and ashore units. This system "does not 
currently have sufficient capacity to provide full time 
data communications services for decision/mission 
support (administrative) information systems." 

[Ref. 11] 
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explore the affects of implementing a shipboard 



19 



interface with the DDN. This would serve as an 
alternate method of transmitting information currently 
sent via the NTS while also providing a more efficient 
means of completing shipboard administrative work. 

2 . Naval Telecommunications System Description 

Satellite communications have become the most 
utilized medium for rapid information exchange in the 
U. S. Navy. The Fleet Satellite Broadcast Subsystem 
(FSB) has evolved as a natural expansion of the Fleet 
Broadcast. The Fleet Broadcast has historically served 
as the primary communications medium for naval 
operating forces. [Ref. 12] General service naval 
messages are transmitted over either the Fleet 
Satellite Broadcast Subsystem or the Common User 
Digital Information Exchange/Naval Modular Automated 
Communications Subsystem ( CUDIXS/NAVMACS ) . 

The FSB provides shore to ship transmission of 
messages from shore based terminals at Naval 
Communications Area Master Stations/Naval 
Communications Stations ( NAVCAMS/NAVCOMMSTAs ) to ships 
via Ultra High Frequency (UHF) satellites. The ships 
monitor the communications traffic and copy information 
intended for their unit. Message traffic is controlled 
and queued automatically by the Naval Communication 
Processing and Routing System (NAVCOMPARS) located at 
the NAVCAMS. Messages may be entered into the 
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NAVCOMPARS processor from the over the counter 
facilities of NAVCAMS/NAVCOMMSTA or from the interface 
to the Automatic Digital Information Network (AUTODIN). 
This subsystem operates with a data rate of 75 bits per 
second (bps) per channel. [Ref. 13] 

The CUDIXS/NAVMACS system provides the 
alternate method of satellite transmission for naval 
messages. CUDIXS consists of shore based message 
processors and peripheral equipment. NAVMACS is the 
shipboard counterpart of CUDIXS, consisting of message 
processing and distribution equipment. Together, 
CUDIXS/NAVMACS forms a ship to shore and shore to ship 
system capable of providing operational communications 
at the relatively high rate of 2400 bps. [Ref. 14] 

It is important in evaluating available 
bandwidth for message transmission over the NTS to 
examine the entire NTS UHF Satellite System. All 
satellite communication subsystems compete for the 
limited channel assets. The Commander, Naval 
Telecommunications Command ( COMNAVTELCOM ) provides 
operational direction and management of the satellite 
system to best satisfy the requirements of the CNO and 
Fleet Commanders in Chief (FLTCINCs). [Ref. 15] There 
is increasing demand for these satellite channels. As 
the demand for subsystems such as Officer in Tactical 
Command Information Exchange Subsystem (OTCIXS), 
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Submarine Satellite Information Exchange Subsystem 
(SSIXS), Tactical Intelligence Subsystem (TACINTEL), 
Secure Voice Subsystem, and Tactical Data Information 
Exchange Subsystem (TADIXS) increase, the availability 
for the traditional naval message channels, like FSB, 
becomes much more restricted. [Ref. 16] 

Improvements in multiplexing techniques, such 
as Demand Assigned Multiple Access ( DAMA ) , have 
enabled the more efficient utilization of available 
bandwidth. However, this has been matched with a 
decreasing number of available satellite channels. The 
current Fleet Satellite Communication (FLTSATCOM) 
satellites are being replaced with Leased Satellite 
( LEASAT ) satellites. FLTSATCOM satellites have ten 25 
kilohertz (Khz) channels dedicated to Navy 
communications . The LEASAT satellites have only six 25 
Khz channels for the Navy. These trends mandate strict 
control of the limited communication resources. 
Requests to expand each of the subsystems have also 
increased. Through strict circuit management 
communication requirements have been met. As fleet 
commanders develop reliance on the various satellite 
subsystems, FSB and CUDIXS/NAVMACS channels become 
limited with no room for growth. Maximum utilization 
of the existing bandwidth becomes critical and methods 
which minimize usage become essential. 
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When the volume of message traffic Increases 
there is a concurrent Increase in the backlog of 
message traffic to be sent. This results in 
increasing the time of receipt for message 
transmission. The time it takes for an outgoing 
message to be received at its destination is referred 
to as speed-of-service . The Navy has established a 
maximum allowable speed-of-service for the different 
classifications of naval messages (Table 1). When an 
increase in the backlog results in the speed-of-service 
approaching these maximums the NAVCAMS take action to 
ensure these times are not exceeded. The 
implementation of the removal of administrative traffic 
from the fleet broadcast is an example of how the 
NAVCAMS can react to maintain the required speed-of- 
service. [Ref. 17] 



SPEED-OF-SERVICE 



PRECEDENCE 


PROSIGN 


OBJECTIVE 


FLASH 


Z 


10 MIN. 


IMMEDIATE 


0 


30 MIN. 


PRIORITY 


P 


3 HOURS 


ROUTINE 


R 


6 HOURS 




TABLE 


1 [REF. 18 



3 . Message Control 

Three methods of control are used to help 
manage the message loading and ensure that critical 
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naval message traffic is transmitted in a timely manner 
during periods of heavy demand. Additionally, EMCON is 
discussed regarding its impact on electronic 
transmission of information. 

a. MINIMIZE 

The first method is MINIMIZE. MINIMIZE may 
be implemented whenever an emergency arises, or is 
anticipated, which requires a reduction in 
communications transmitted over U. S. 

telecommunications facilities. The imposition 
MINIMIZE requires that all message releasing officers 
review and certify that the following condition has 
been met. Only message traffic that directly concerns 
the accomplishing of a mission or safety of life is 
considered essential and may be transmitted 
electronically. All non-essential messages will be 
transmitted by other means. This action both informs 
the operating forces that the NTS is limited in its 
capacity to handle the normal volume of message traffic 
and places the ability to manage the information 
transmitted directly in their hands. [Ref. 19] 

b. Administrative Message Designation 

The second method of control allows the 
FLTCINCs to stop administrative message traffic from 
being transmitted over the fleet broadcast during 
periods of crisis or when overloads occur. This 
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administrative traffic is stored until conditions 
return to normal, allowing transmission. Currently, 
all naval messages of an administrative nature are 
required to include the word "ADMIN" in the message 
handling instructions. "ADMIN" messages are identified 
by the addition of "ZYB" at the end of the date-time- 
group line. The administrative designation is assigned 
by the message drafter. When the FLTCINC orders the 
removal of administrative traffic, the effect is to add 
additional levels of precedence to the messages. This 
results in higher priority "operational" messages 
having a faster speed-of-service , thus ensuring that 
vital messages are transmitted first. [Refs. 20,21] 
c. NAVGRAM Program 

The third method to aid in the control of 
the number of messages is the establishment of the 
Navy Mailed Message Program (NAVGRAM). This was 
established as part of the message reduction program 
initiated in 1985. The NAVGRAM program provides a 
means to reduce the number of electrically transmitted 
messages. The message is written on the DD 173 Joint 
Messageform but is mailed instead of being electrically 
transmitted. NAVGRAMs are given priority over routine 
correspondence, may contain up to fifteen addressees, 
may be readdressed and may be referenced. They are 
designed to provide the originator the ease and 
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priority of a naval message without increasing the load 
on the NTS. This is essentially a newer version of the 
Naval Speedletter. [Ref. 22] 
d. EMCON 

An additional policy which impacts message 
transmission is Emission Control (EMCON). EMCON may be 
imposed at the discretion of the officer in tactical 
command. EMCON policies prohibit using specific 

frequencies of electromagnetic transmission. 

Depending on the particular EMCON plan imposed, the 
impact may vary from partial to total loss of 

communication equipment. It is conceivable that EMCON 
may be imposed for extended periods of time thereby 
requiring alternate methods of information exchange. 
This suggests the use of physical transfer of data on 
magnetic tapes, disks, Compact Disk-Read Only Memory 
(CD-ROM) or Write Once, Read Many (WORM). 

4 . NTS capacity limitations 
a. Fleet input 

In discussions with communications 
personnel, several important points have been made. 
[Refs. 23,24] Communications demand is being met. 
Management policies dictate that speed-of -service 
requirements be attained and this is being 
accomplished. A trade-off does occur, however, in that 
FLTCINCs specify which users get what channels. It is 
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not possible to grant all requests for bandwidth due to 
limited assets. Some users must exist with less than 
optimum data rates as a result. On both coasts the 
deletion of "administrative" traffic has been imposed 
to maintain speed-of-service for operational traffic. 
Essentially, while the NTS is able to satisfy 
operational message requirements, it occasionally 
experiences difficulty. This difficulty is only 

getting worse and is limiting the NTS ’ s ability to meet 
the demand for administrative/mission support messages 
and data. Mission support information is as important 
as operational information in ensuring the continued 
preparedness of Naval forces. 

b. Administrative versus Operational Messages 
(1) Definitions . As stated above, current 
telecommunications procedures require that 

administrative messages be labeled as such. 
Presumedly, traffic not labeled administrative is, in 
fact, operational. Examples of traffic that is 

administrative in nature include "personnel actions, 
newsgrams or USN publication changes." [Ref. 25] This 
very general and nondescript definition of 
"administrative" allows the strong probability that 
additional message traffic could, and perhaps should, 
be placed into the administrative category. Many 

i 

communicators have indicated a desire to change this 
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requirement by requiring an "operational" label instead 
of "administrative" as an attempt to obtain a more 
accurate segregation between the two. A very specific, 
but classified description of "operational" is provided 
in Naval Warfare Publication (NWP) 4. [Ref. 26] 

(2) Pol i cy . The administrative 
definition has been left intentionally vague to allow 
operational commanders to exercise their command 
authority in the determination of message traffic 
classification. During operational exercises the 
speed-of-service often degrades significantly in 
response to the increase in message traffic. 
Commanding officers respond by increasing the priority 
classification assigned to their messages to ensure 
timely receipt. It is logical to assume that these 
same commanding officers will exhibit similar 
tendencies by excluding the "administrative" 
designation of administrative messages when they feel 
the necessity for timely transmission. 

(3) Lack of Enforcement . There is no 
concerted effort to ensure that commands properly 
designate administrative traffic. The Naval 
Communications Area Master Stations (NAVCAMS) do not 
have adequate manning levels to verify compliance. The 
Naval Communications Processing and Routing System 
(NAVCOMPARS) is programmed only to act on messages 
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designated "administrative" when directed to delete 
such traffic from the fleet broadcast. The NAVCOMPARS 
does not, for example, check Standard Subject 
Identification Codes (SSICs) as a method of separating 
operational from administrative traffic. The FLTCINCs 
do spot screen traffic on a random basis and notify 
non-complying units. 

(4) Statistics . While statistics are not 
kept on this type of information, it is reasonable to 
assume that less than fifty percent of the message 
traffic is truly "operational" during non-crisis 
operations. Current figures indicate that 
approximately twenty percent of naval messages are 
designated as "administrative" by their originator. 
[Ref. 27] 

CNO policy calls for ship schedules 
providing a minimum of fifty percent time spent in 
homeport. By having inport ships transmit these 
messages over the DDN instead of the NTS, the number of 
NTS messages would be significantly reduced. Allowing 
for the fifty percent inport time and using the twenty 
percent administrative traffic figure, we could expect 
the number of messages transmitted over the NTS to be 
reduced by at least ten percent. Additionally, it may 
also be true that more efficient communications in 
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homeport will result In a higher level of preparation 
thereby reducing the demand for at-sea communications. 



B. SHIPBOARD ADP 

1 . Shipboard Information Problems 

In December 1987, VADM J. Metcalf III, Deputy 
Chief of Naval Operations (Surface Warfare), lead the 
Introduction of the "Paperless Ship" Initiative. He 
did this to alleviate the problems caused by "the 
present methodology of using, storing and maintaining 
paper products (which) was having an adverse affect on 
the ship’s warfighting capability." [Ref. 28] The 
problems addressed are twofold. First, ship’s force 
personnel currently spend an excessive amount of time 
processing Information resources. This time could be 
better utilized In other areas. Second, the volume and 
weight used by these paper products directly Impacts 
the ship’s combat capability by reducing stability and 
endurance . 

The Intent of the Paperless Ship" Is best 
summarized as follows: 

( The )... reduct ion of paperwork Is not the 
objective of this Initiative, but rather the 
Improvement in information transfer and 
management. The real issue of the ‘Paperless 
Ship’ Is Information; how to improve access to 
information and how to wean the ship from paper. 
Integration of information is important toward this 
end. Moreover, the concern should be on 

information flow in the ship with the 

responsibility for maintenance of this information 
transferred to the shore establishment. [Ref. 29] 
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a. Too Much Paper 

The initial investigations of the 
"Paperless Ship" initiative revealed that enormous 
quantities of paper are maintained aboard ships. This 
included over 20 tons on a FFG-7 class frigate and 37 
tons on a CG-47 class cruiser. [Ref. 30] Both of these 
ship types are extremely weight critical. This large 
quantity of weight is simply not acceptable. 
Additionally, this vast amount of paper requires many 
man-hours for processing, updating and information 
retrieval. Much of the paper is required for recurring 
reports which must be completed on specified forms. 

Initially, proposed solutions to this 
problem center on optical storage technology. CD-ROM 
and WORM systems could be integrated with SNAP or the 
proposed intelligent Z-248 Zenith terminals for the 
SNAP system. CD-ROM could provide technical manual and 
instruction type information. This would eliminate the 
need for ship’s personnel to perform manual updates by 
simply receiving regularly updated copies of all 
necessary information via new CD-ROM disks. [Ref. 31] 
This information would also be much more accessible 
through the use of computer driven indexes which would 
quickly display the information requested. Required 
information and reports could be maintained using WORM 
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technology, thereby reducing large volumes of paper to 
several small disks. 

b. Duplication of Effort 

The SNAP system is currently experiencing 
problems in the area of acceptability. This occurs 
both within and outside the command. Feedback 
indicates that there is an apparent policy lag in the 
acceptance of afloat automation. Examples include the 
fact "that some inspection teams are not accepting SNAP 
records" [Ref. 32] and hard copy data is often required 
by receiving organizations in addition to magnetic 
tapes. Internally, some commands require that reports 
and messages be reviewed on paper as opposed to the 
computer screen. This requires additional or duplicate 
work to be generated on the very system which was 
designed to eliminate this problem. The extra 

generation of this information also increases the 
probability of errors being introduced into the data. 

2 . Shipboard ADP Systems-Hl story 

During the 1970 ’s, technological advances in 
microprocessors produced significant cost reductions in 
electronics and communications. This spawned an 
increased interest in computers. At the same time 
constrained budgets and increasing personnel costs were 
driving manpower officials to begin to examine methods 
to increase the productivity, efficiency and accuracy 
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of administrative personnel. Several studies involving 
the use of ADP equipment on ships were conducted. 
Commercial procurement of minicomputer systems which 
were provided to test platforms yielded positive 
results. Studies were conducted aboard USS Gridley 
(1975) [Ref. 33], and USS Coontz and USS Arthur W. 
Radford (1980) [Ref. 34]. The bottom line in the 
findings of these studies indicate that: (l) "a 
microcomputer system with a data management and word 
processing capability can have a major impact on 
reducing shipboard administrative burden and, in turn, 
can contribute to day-to-day ship operating efficiency" 
[Ref. 35] (2) the amount and type of training, 
documentation and on-board expertise directly impacts 
the benefits obtained from the system (3) the degree 
of system use and application development was related 
to the command interest generated by the commanding 
officer and to extent to which the system is "user- 
friendly." [Ref. 36] 

In 1975, the Chief of Naval Operations 
established the Shipboard Non-tactical ADP Program 
(SNAP) to provide assistance in the accomplishment of 
shipboard administrative functions. The Fleet Non- 
tactical ADP Requirements Definition Working Group 
identified requirements for SNAP application programs 
in their November 1976 report. [Ref. 37] 
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SNAP 



3 . 

The Shipboard Non-tactical ADP Program exists 
as two separate programs. SNAP I was established in 
response to problems created by the aging AN/UYK-5 (V) 
computers used aboard large Naval ships and shore 
activities. This involved replacement of existing 
hardware with the AN/UYK-65 (V) and upgrading 

application software. SNAP I is installed aboard 
supply ships, repair ships, amphibious ships, aircraft 
carriers afloat. Shore Intermediate Maintenance 
Activities (SIMAs), Naval Air Stations and training 
commands ashore. SNAP II is designed for the 

remainder of the surface navy and submarines, providing 
these ships with ADP capabilities compatible with SNAP 
I computers. 

a. System Overview-Purpose 

SNAP II evolved around the 1980 CNO 

Objective Number 5 to "reduce the administrative burden 

on the fleet." [Ref. 38] SNAP II systems are designed 

to run in unmanned spaces without dedicated operators. 

Maintenance and operation is to be accomplished without 

increases to existing shipboard manning levels. The 

hardware used in SNAP II systems is the Harris series- 

300 minicomputer with ruggedized off the shelf 

commercial peripheral equipment. 

It is the objective of the SNAP II to provide 
automatic data processing equipment to all 
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submarines and surface ships ... Through the use of 
ADP equipment in support of maintenance, supply, 
pay and personnel, the timeliness and accuracy of 
data and reported information will be greatly 
improved. Additionally, the time consuming and 
error prone manual preparation of forms will be 
reduced. [Ref. 39] 

b. System Capabilities/Applications 

Navy Management Systems Support Office 
(NAVMASSO) is tasked as the SNAP Central Design 
Activity (CDA) to be responsible to identify ADP 
requirements, analyze, design, program, implement, 
maintain and provide life cycle support for the system. 
NAVMASSO serves as a single point of contact for 
overall coordination of SNAP I and II. NAVMASSO is 
responsible for the development, testing, installation 
and documentation maintenance of both hardware and 
software. NAVMASSO provides training and assistance to 
fleet users in the implementation, use and operation of 
SNAP. Additionally, they review training curricula 
lesson plans and monitor courses for accuracy and 
method of presentation. [Refs. 40,41] 

The following subsystems serve as the 
foundation of the SNAP system. Additional subsystem 
modules are currently being developed and installed to 
augment the core group discussed below. These include 
Food Service Management Afloat, Resale Operations 
Management and SNAP Automated Medical System. [Ref. 42] 
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( 1 ) System Management Subsystem (SMS) . 

This performs system management and system service 
tasks in support of the other subsystems. It 
protects system data integrity through transaction 
backup, recovery, and transaction logging 
functions. Although most SMS functions will be 
invisible to the system user, two functions a user 
knowingly will use are the send/receive mail 
function and the on-line users manual. The mail 
function will allow users to send, receive, and 
display mail or messages throughout the ship. With 
an on-line users manual, users can view or print 
guidance for any available subsystem included with 
their SNAP II equipment. [Ref. 43] 

( 2 ) Maintenance Data Subsystem (MDS) . 
This subsystem provides an automated maintenance 
capability. The Current Ships Maintenance Program 
(CSMP) is maintained up to date with on-line interface 
with maintenance actions recorded by OPNAV 4790/2K or 
4790/CK forms. The on-line interface between supply 
and maintenance functions to assist in parts ordering 
with direct access provided to the ship’s Consolidated 
Ships Allowance Listing (COSAL). Equipment 
identification, maintenance action deferral and 
accomplishment, and parts ordering and approval are 
also automated through this subsystem. 

( 3 ) Supply and Financial Management 

Subsystem (SFM) . This subsystem automates current 
supply procedures providing support in supply and 
financial management areas. Both maintenance and 
supply personnel use this system. Parts 
requisitioning, requirements review, COSAL access, and 
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budget review are functions commonly utilized by 
maintenance personnel. Supply personnel perform the 
majority of their functions on SFM. Financial reports, 
files and records are maintained by this system. 
Examples include COSAL file, budget operating target 
(OPTAR) file, constants file, requirements file, 
requisition status file, stock record file, transaction 
ledger maintenance, and cross reference file. [Ref. 44] 

( 4 ) Administrative Data Management 

Subsystem ( ADM ) ♦ This subsystem provides 

administrative support capability for both shipwide 
functions and departmental/divisional requirements. 
Examples include basic word processing, watchbill 
assignments, career counseling records, Watch, Quarter 
and Station assignments, general personnel records and 
medical/dental records. 

(5) Source Data System ( SDS ) . This 
subsystem provides for bi-directional communications of 
pay and personnel data between the ship. Navy Finance 
Center and Naval Military Personnel Command. SDS is 
the precursor of the Source Data System Afloat (SDSA) 
system discussed in Chapter VI. 
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IV. DEFENSE DATA NETWORK -THE CONNECTOR 



This chapter provides a quick overview of the 
Defense Data Network and the specific applications 
directly beneficial to the operating forces. 

There are many good references which provide 
excellent descriptions of the evolution of the Defense 
Data Network [Refs. 45,46,47]. Documentat ion 
explaining the DDN as it exists today is also readily 
available [Refs. 48,49,50,51]. The interested reader 
is invited to review these references. 

A. BACKGROUND HISTORY 

The Defense Data Network evolved from the Advanced 
Research Projects Agency Network (ARPANET), a research 
and development project sponsored by the Defense 
Advanced Research Projects Agency (DARPA). ARPANET was 
established in 1969 as an experimental network for the 
advancement of state-of-the-art computer resource 
sharing. This system proved extremely successful and 
operational users quickly began to proliferate. By 
1975 the number of operational users was great enough 
to transfer control of the network from DARPA to the 
Defense Communications Agency. In 1982 the Defense 
Data Network was created using ARPANET technology to 
link Department of Defense computers together. The DDN 
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currently exists with separate classified and 
unclassified segments. It is the unclassified, 
Military Network (MILNET) segment of the DDN that this 
thesis deals with. [Refs. 52,53] As mentioned 
previously, Department of Defense policy states that 
all data networks requiring long-haul communications 
will be connected by the DDN. 

B. NETWORK OVERVIEW 

The DDN architecture utilizes packet switching as 
its method of handling data transmission. In this case 
the information to be transmitted is passed from the 
"host" computer with its destination address to a local 
Packet Switching Node ( PSN ) . The PSN divides this 
information into small "packets" of a prescribed size 
and routes these packets with a sequence number to the 
original destination address. These packets are 
individually routed from PSN to PSN with each packet 
using the best route available at the time. The route 
chosen may vary depending on congestion and 
availability of circuits. The destination PSN 
reassembles the packets in the proper sequence and 
forwards the original information to the destination 
computer. Error checking and correction are provided 
by each PSN to ensure that the transmitted information 
is complete and accurate. [Ref. 54] 
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The DDN is composed of two functional areas; the 
backbone network and the access network. The DDN 
backbone is designed to be highly survivable with a 
network of over 200 PSNs located throughout Europe, the 
United States and the Pacific. Backbone transmission 
links are land-based circuits capable of 56,000 bps 
data rates. European circuits are 9,600 bps lines. 

The access network consists of host systems 

connections and terminals. 

The host systems are connected to the DDN packet 
switches using either X.25 or ARPANET (1822) 
interfaces. The transmission speeds of the host 
access circuits will be 9,000 to 56,000 bps. Each 
host system can be directly connected to one or 
more packet switches by one or more circuits. 



Terminals are directly connected to the network 
through either a Terminal Access Controller ( TAC ) 
or a mini-TAC, or may be indirectly connected 
through a host which is itself directly connected 
to the network. The TAC supports 63 terminals; the 
mini-TAC supports 16. Terminals are connected to 
TACs or mini-TACs with either direct lines 
operating at speeds ranging from 110 to 9,600 bps 
or dial-up lines operating from 110 to 2400 bps. 
Each of the TACs is connected to a packet switch in 
the network backbone via direct line operating at 
9,600 to 56,000 bps. [Ref. 55] 



The 



DOD 



standard 



Transmission 



Control 



Protocol / Internet Protocol (TCP/IP) is used to handle 
end-to-end data flow between two systems. This is used 
for both host-to-host and host-to-TAC connections. 



C. SHIPBOARD APPLICATIONS 

While the DDN provides many capabilities and 
applications for information exchange the following are 
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the most applicable for immediate utilization with 
shipboard ADP equipment. In the near term, DDN 
connections will only be possible with ships inport. 

1 . Electronic Mail 

Electronic mail is the most used service on the 
DDN. This capability allows messages to be sent to 
users on the same host or to be sent to users residing 
on different hosts. Electronic mail programs 
automatically translate messages to the correct format 
for the receiving host and store messages until the 
recipient is ready to receive them. The recipient can 
then read, print, move or delete the messages. 
Readdressal and reply capabilities are available on 
electronic mail programs. Text editors are available 
for message preparation and separate files may be 
inserted as the text of a message for transmission. 
[Ref. 56] Simple Mail Transfer Protocol (SMTP) is used 
to provide transfer of electronic mail over the DDN. 

Electronic mail provides a capability similar 
to naval messages. It satisfies the requirements for 
information transfer that are necessary for commands. 
Electronic mail is easy to use and eliminates the 
necessity of administrative personnel. It allows the 
sender to provide information to multiple recipients 
while keeping a record copy for the originator. If the 
mail is undeliverable the originator is informed of 
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that fact. Finally, the speed-of-service Is extremely 
fast. This system would satisfy the requirements of 
administrative message traffic, while reducing the 
human overhead needed when using the NTS. 

Of all the DDN services, electronic mail could 
become the most beneficial. Its greatest benefit lies 
in the fact that it can be used effectively for both 
official and informal communications. Messages could 
be identified as "official" when desired by the 
originator. Information transmitted in this manner 
would have the same impact as naval messages sent over 
the NTS. The NTS, however, would not have these 
messages entered into its system, thereby reducing NTS 
traffic volume. 

Equally important are the potential benefits 
gained by the use of electronic mail in informal 
communications. It serves as an excellent medium for 
improving subformal communications. This results in 
increased productivity due to improved information flow 
throughout the organization. 

Efficiency improvements include less lost time 
in attempting to complete phone conversations. Phone 
conversations are often disruptive for both parties. 
Callers spend too much time getting busy signals or 
finding that the person he is attempting to reach is 
not available. The recipient is often called away from 
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important functions, interrupting daily schedules. 
With electronic mail, messages are sent and replied to 
at the convenience of the individual parties. An 
obvious example would be the benefits of having officer 
and enlisted detailers with electronic mail capability. 
Efficiency on behalf of both the detailers and 
personnel would be improved. There are also intangible 
benefits to be gained through increased personnel 
satisfaction . 

2 . File Transfer Protocol 

The File Transfer Protocol (FTP) provides the 
capability to transfer files from one computer to 
another. The files may be data, text or programs. FTP 
handles the transfer even when the computers use 
different operating systems or file storage formats. 
All that is required is the remote host’s address, a 
username and password for that host, and the specific 
file name. File transfer may be accomplished either to 
or from the remote host. Individual files are provided 
protection which permits file transfer, prohibits 
transfer, provides read only access or prevents access 
to all except the originator himself. [Ref. 57] 

FTP provides the capability to easily send a 
variety of information to required recipients. 
Conversely, it provides the ability for other 
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organizations to obtain information from files without 
requiring intervention from the originator himself. 

Examples of benefits derived from this 
capability include the electronic transfer of work 
packages from a ship to a SIMA or allowing a destroyer 
squadron to extract required ship’s personnel 
information from the ship’s database without requiring 
the ship to perform additional work. 

The potential of FTP for shipboard personnel is 
most impressive. The ability to transfer required 
information off ship without additional work would be a 
huge time saver. Currently, information sent off ship 
must be prepared, formatted and transmitted. This is a 
redundant, time consuming process. 

The vast majority of the information needed for 
recurring reports is maintained on file, often in 
existing SNAP system programs. This includes general 
administrative items in addition to the 3-M and supply 
information. Safety reports, personnel reports, 
training status and personnel qualifications are 
examples of information often requested from senior 
commands. This information could simply and 
immediately be transmitted to the requesting command. 
Additionally, strong programs or good instructions from 
a particular ship can be shared throughout the squadron 
with minimal rework required by the receiving ships. 
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Currently, it is common for this information to be 
shared via paper copies or In some cases magnetic 
disks. This often requires much manual Intervention by 
each receiving ship. There is often a breakdown in the 
transfer of this type of information resulting in 
inadvertent omission of some commands. FTP ensures 
that all information is available in usable form to all 
ships. A FTP capability would reduce paperwork and 
administrative time, resulting in increased 
organizational slack. 

3 . Others 

The DDN provides other capabilities which, 
although not essential, could prove beneficial and 
should be considered for inclusion in the shipboard 
ADP/DDN interface. Bulletin boards could be 
established to address points of interest in specific 
subject areas, for example, surface-to-air missiles, 
gas turbine engines, administrative procedures, etc. 
This could serve as a near real-time forum for the 
discussion of problems and sharing of solutions. WHOIS 
functions as an electronic white pages which provides 
information on DDN users including their DDN address, 
mail address and phone number. WHOIS provides search 
capability based on name, partial name, DDN handle, 
hostname, TAC name or Node name. TELNET allows users 
to log on to a remote host and to use its capabilities 
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just as if logged on directly. TALK allows real time 
interactive communication between two locations 
residing on the same host. [Ref. 58] 

A most promising area to explore is that of 
using the combination of TELNET and FTP capability to 
allow senior commands the ability to extract required 
information from ship’s databases. This would allow 
these commands to query individual ships when 
information is needed. While FTP would be used for 
providing information for recurring reports, special 
and one time reports could be best handled by logging 
into the ship’s system and examining the required 
information. This eliminates the additional 
administrative burden imposed upon ships and transfers 
it to the shore establishment. 

Side benefits of this type of system include 
the extra pressure on the ships to keep their 
administrative data current. The database would need 
to be maintained in an up to date status since there 
would be no warning of reviews by seniors. This 
provides long term benefits on the ship’s overall 
readiness status and minimizes crisis management 
techniques used to prepare for administrative and 
material inspections. 
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D. SUMMARY 



The capabilities provided by the addition of DDN 
services would have a tremendous impact towards 
reducing the administrative burden on the fleet and 
easing the demand on NTS. It should be noted that the 
largest amount of time devoted to shipboard 
administrative requirements occurs while the ship is in 
homeport. DDN connections at homeport are certainly 
obtainable with minimal financial outlay. A key 
advantage in the DDN services is that they could be 
used to shift the administrative burden ashore, exactly 
where it should be. 

As a final comment, if costing schemes are 
implemented for communications services these types of 
services would shift the cost to the requesting 
command. This would result in a critical review of 
existing requirements and the elimination of 
unnecessary reports. 
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V. CONNECTIVITY 



A. PRESENT SYSTEM 

Currently information provided by ships to other 
organizations can be grouped into two areas. First, 
there are communications which are generated as naval 
messages. Second, there is data type information which 
has been automated through the introduction of SNAP and 
is transmitted physically, usually by mail. This type 
of information includes 3-M information, Military 
Standard Requisitioning and Issue Procedures (MILSTRIP) 
information, Fleet Accounting and Disbursing Center 
(FAACD) data, pay and personnel data, and 
administrative information including official mail. 

1 . Naval Messages 

The Naval Telecommunications System (NTS) 
provides message traffic connectivity between naval 
forces within a local area. While in US Navy ports, 
this transmission is from ships into the NTS via Naval 
Communications Stations ( NAVCOMMSTAs ) or Naval 
Telecommunications Centers (NTCCs) via over the counter 
hand carried service. While at-sea, messages are 
transmitted from ships into the NTS at 
NAVCAMS/NAVCOMMSTA ’ s receivers via fleet UHF 
satellites or over High Frequency circuits. Messages 
sent to a destination activity within the same local 
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area remain within the NTS. Messages requiring out of 
area transmission interface with the Defense 
Communications System (DCS) through AUTODIN Switching 
Centers (ASCs). Presently long haul communications are 
provided by the DCS Automatic Digital Information 
Network (AUTODIN) which routes messages between ASCs. 
Messages going to Naval activities then re-enter the 
NTS for ultimate delivery to the final destination. 

2 . Physically Transmitted Data 

This information is sent off ship via mail or 
is hand carried by messenger to the receiving 
organization. It may be hard copy, magnetic tapes or 
disks. The system is essentially the same during both 
inport and at-sea periods. The time it takes for 
information to be physically transported to the 
receiving organization is the controlling factor in 
determining the usefulness of the information. While 
ships are in the United States, the mail is reasonably 
fast. Express mail provides overnight service. When 
ships are underway or inport overseas, the mail becomes 
much less reliable and time of delivery can become 
excessive. This often reduces the usefulness of the 
information significantly. Methods to speed up 
information exchange need to be reviewed to determine 
the benefits of improved speed-of-service versus the 



increased cost. 



3 . POD DDN Directive 

On April 2, 1982 the Deputy Secretary of 
Defense issued a memorandum directing the termination 
of the AUTODIN II system and the continued development 
of the Defense Data Network as its replacement. [Ref. 
59] This decision was made after an extensive review of 
the AUTODIN and DDN systems, examining their ability 
to meet the requirements of the future. The study 
determined that the DDN design provided increased 
survivability at less cost. [Ref. 60] 

It was later directed that the DDN would be the 
common user network over which all long haul 
communications of the DOD would be transported. [Ref. 
61] This directive has a tremendous impact upon the 
way information exchange is viewed in the Navy. It 
impacts not only the way computer information is 
transmitted but also the way in which messages are 
routed when they are transported out of a local NTS 
area. In the future, naval messages will be routed 
into the DCS via the more capable Inter Service/Agency 
Automated Message Processing Exchange (I S/A AMPE ) DDN 
equipment instead of the current ASCs. This major 
equipment change presents an opportunity for critical 
review of the present system and an examination of the 
potential impact of the DDN interface on other 
applications . 
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4 . Present System Shortfalls 

The current system has several significant 
Inadequacies. Essentially, the system is unable to 
provide satisfactory speed-of-service in the quantities 
required. The NTS was not designed with the capability 
to handle administrative information. As a result it 
is unable to provide this service when the system is 
stressed due to increased operational tempo. The 
"administrative" message designation was created to 
accommodate this situation. While the NTS can maintain 
the present level of non-operat ional traffic, 
additional methods of transmitting this information are 
required . 

When naval messages are not used, the result is 
excessive delivery times. Mail service does not 
provide sufficient speed for many types of information. 
Personnel pay records, obligational financial 
information, maintenance information and parts 
procurement are examples of data which is very time 
sensitive. There is also significant administrative 
effort consumed in the preparation and mailing of the 
data and the coinciding repeat performance on the 
receiving side. 

The Navy's information demands are rising at 
the same time that budgetary and personnel constraints 
are becoming limited. The present system’s 
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inadequacies have resulted in examining new methods to 
meet this demand. 

B. THE FUTURE: THE NDCCA 

The Navy is currently exploring the development of 
an all encompassing data communications system: Navy 

Data Communications Control Architecture (NDCCA). The 
Director of the Department of the Navy Information 
Resources Management has assumed the lead role as 
coordinator for this program which has a implementation 
target date of 1995. NDCCA will establish the baseline 
for all decision/mission support data transfer between 
ship and shore units. Decision/mission support data is 
essentially all data exchange of a non-tactical nature. 
[Ref. 62] 

A review of information, available only in draft 
form, shows great insight and promise. 

NDCCA is the top level architecture which describes 
the overall system for Navy data communications. It 
provides for the identification and promulgation of 
policy, standards and guidance for future evolution. 
This top level structure is broken down into three 
physical locations; afloat, ashore and long haul. The 
afloat architecture includes shipboard and ship-to-ship 
components. Two additional segments, security and 
protocol, have recently been included to specifically 
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address these particular areas of data communications. 
[Ref. 63] 

1 . Base Information Transfer System (BITS) 

Base Information Transfer System (BITS) will 
integrate voice and data for intrabase communications, 
interbase communications and decision/mission support 
systems. Intrabase communications includes electronic 
mail, data access and file transfer between office 
automation networks (OANs) located throughout the base. 
Interbase communications are provided through AUTODIN, 
DDN , and commercial data networks. This will include 
OAN to DDN connections and an interface to AUTODIN via 
NTCCs for formal message traffic transmission. The 
decision/mission support system will provide pier 
facility connections allowing ships to interface with 
BITS directly. BITS will then make the required 
connections for long haul communications. [Ref. 64] 

Essentially, BITS will handle all local 
communication requirements ashore. This specifically 
will include file transfer, interactive terminal to 
host computer capability, electronic mail, video 
teleconferencing, record (naval message) 
communications, voice transmission and connections to 
both SNAP and long haul systems. Voice communications 
will initially be handled through Private Automatic 
Branch Exchange ( PABX ) and then updated to the 
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Integrated Services Digital Network (ISDN). Data 
communications will initially provide for LAN to DDN 
connections, with DDN being upgraded to Integrated Data 
Services (IDS). Message communications will initially 
be handled through AUTODIN and eventually upgraded to 
IDS. [Ref. 65] 

2 . Long Haul Data Communications Architecture 
( LHDCA ) 

The Long Haul Data Communications Architecture 
(LHDCA) will be satisfied by the DDN. This includes 
both data and naval message communications. For 
message communications the current AUTODIN Switching 
Centers (ASCs) will be replaced by the automated I S/A 
AMPE during the conversion to DDN. ISDN architecture 
is planned which will integrate voice, secure voice and 
data services. Users will have a single access for 
these services. The backbone networks include Defense 
Switched Network (DSN), DDN and commercial services. 
[Ref. 66] 

3 . Afloat Data Communications Architecture (ADCA) 
The Afloat Data Communications Architecture 

(ADCA) establishes: 

...the baseline for enhancing the transfer of 
decision/mission support data between ships (at-sea 
and in-port) and the interface to the shore-based 
connection to the long haul communications network, 
as well as ship-to-ship and shipboard. [Ref. 67] 

It is subdivided in to four segments. 
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a. Ship-at-sea 

This will be designed to handle the 
increased volume of traffic using technology 
improvements. These improvements include using data 
compression techniques and conversion from character 
oriented message formats to bit oriented message 
formats. Additionally, information filters are to be 
developed to screen data to determine the best method 
of transmission. This system would also include 
automatic format conversion where necessary. This 
system would allow the segregation of data into 
essential information, to be transmitted over the NTS, 
and information of a lesser priority which could be 
sent on tape, disk, CD-ROM or WORM. [Ref. 68] 

b. Ship-in-port 

This will allow ships inport to by-pass the 
existing NAVCAMS/NAVCOMMSTA structure and handle file 
transfers directly using BITS connections to enter into 
the DDN. In addition to file transfer, this system 
will provide the capability for interactive 
communications and electronic mail. [Ref. 69] 

c. Ship-to-ship 

File transfer and interactive 
communications are necessary to provide the ability to 
conduct parts screening aboard local ships and work 
package transmittals to tenders. The current proposal 
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is to conduct these transfers inport over direct 
communications links and to continue to investigate new 
methods for at-sea transfers. [Ref. 70] 

d. Shipboard 

Methods to reduce manual intervention 
requirements will be implemented. This will include 
the installation of a direct SNAP/NAVMACS interface. 
The decision filters discussed above will be an 
integral portion of this architecture. Shipboard LANs 
are proposed to upgrade SNAP installations. [Ref. 71] 

4 . Evaluation 

The NDCCA demonstrates the Navy’s interest in 
developing a long term solution to its increasing 
information exchange requirements. It provides a top 
down, modular approach utilizing standardized 
interfaces to connect the entire system. While still 
in the developmental stages, the NDCCA is examining 
various standards and policies. It will then 
promulgate these standards as the new requirements for 
the Navy. The great advantage in this approach is that 
it is evolutionary in nature while still utilizing 
state of the art technology. Current systems will be 
merged into NDCCA. This serves to minimize risk while 
allowing for ongoing cost benefit reviews of each 
segment. The NDCCA appears to be a well conceived 
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architecture which should satisfy the Navy’s 
communications requirements of the future. 

C. INTERIM PROPOSAL 

With NDCCA scheduled for implementation around 
1995, an interim solution to handle the Navy’s 
information exchange requirements must be developed. 
The following is offered as a method to meet current 
demands while growing towards the planned NDCCA. 

1 . NAVDAC Host Computer Service 

The DDN replacement of AUTODIN for long haul 
communications transfer will produce a direct interface 
with the NTS. This provides the opportunity for 
orderly evolution towards the NDCCA. Any information 
exchange proposal should provide for the connection of 
shipboard SNAP computers to the DDN. This can be 

accomplished through the use of host computers 
providing storage capability ashore in the form of 
"mailboxes" for individual ships. These mailboxes 
would accept information and store it until the ship is 
capable of downloading it to it’s own SNAP computer. 
The host computer would likewise accept information 
from the ship for further transfer to activities 
connected to the DDN. Navy Data Automation Command 
(NAVDAC) would be the logical choice to provide host 
computer services. The DDN would be connected to both 
the host computer and the NTS. 
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This proposal addresses information exchange 
connectivity problems by dividing them into three areas 
determined by the ship’s location. The first area is 
when the ship is inport in its own homeport . The 
second area is when the ship is inport but not in 
homeport. The third area is when the ship is underway. 
This at-sea segment must also address periods of no or 
reduced NTS message communication due to the imposition 
of EMCON or MINIMIZE. 

2 . Inport Homeport 

While inport homeport, ships would utilize 
NTCCs and NAVCOMMSTAs as the interface for all 
electronically transmitted information. This includes 
Naval messages and SNAP data. DDN electronic mail and 
file transfer protocols could be added as an upgrade to 
information exchange capabilities. NTCCs/NAVCOMMSTAs 
are the logical interface point since both long haul 
naval messages and DDN information exchange 
applications will be transmitted over the DDN. Pier 
connections could be provided for high speed data 
lines, preferably fiber optics, to Join ships and 
NTCCs/NAVCOMMSTAs. These communications facilities 
would provide TAC services for DDN functions, routing 
appropriate information to the DDN and into the NARDAC 
host computer. NAVCOMPARS processing protocols would 
be updated to permit automatic routing and the required 
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format changes of electronic mail, FTP requests and 
naval messages for entry into the DDN. The NARDAC host 
computer would provide services for each ship 
homeported in its region of responsibility. Naval 
messages requiring long haul transmission would be 
routed to the assigned I S/A AMPE and into the DDN. 
Naval messages staying within NTS would be transmitted 
over satellite or HF fleet broadcast circuits using 
current procedures. 

3 . Inport Not Homeport 

Connections can be made using modems. 
Dedicated leased data lines are preferred, when 
available, and dial phone lines are acceptable. These 
phone connections would tie in to the nearest available 
DDN TAC . Via this connection, electronic mail and FTP 
requirements would be transmitted to the ship’s host 
computer mailbox. At the same time the ship would 
download all new information being held in its 
mailbox. Unclassified message traffic would then be 
sent from the host computer to a NTS interface where it 
would be converted into the correct message format and 
forwarded appropriately. Unclassified, administrative 
naval message traffic could be downloaded to the ship 
in a reverse procedure. This entails conversion by 
NAVCOMPARS equipment at the NAVCAMS, changing the naval 
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message format into electronic mail format capable of 
being transmitted over DDN . 

4 . At-sea 

The real problem in providing DDN connections 
for information exchange occurs with ships at-sea. 
While the NTS can provide a limited capability in this 
area, it is virtually impossible with current equipment 
to handle all of the required information. Several 
approaches are available for consideration. A 

combination of these approaches is necessary to 
optimize information exchange overall. 

a. NAVMACS 

The CUDIX/NAVMACS provides transmission to 
NAVCAMS where naval messages are transmitted following 
current procedures. SNAP data transfer can be 

accommodated using this means when necessary. 

Presently some ships have papertape interface between 
SNAP and NAVMACS systems. This can be upgraded to 
electronic transfer using tape or disk as the interface 
media. By using the same switching protocol addressed 
in the previous section this information could be 
automatically be converted to proper format and 
forwarded to the correct destination. Information for 
transmission in this manner could be placed in a queue 
in the NAVMACS system aboard ship and transmitted when 
the loading on NTS assets permits. Close attention to 
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a prioritization scheme which would allow only high 
priority information to be sent via this method is 
essential. Alternate methods of information exchange 
would be preferable from a cost and equipment point of 
view. It is, however, important to remember that 
commanding officers should be allowed to make the 
determination as to the value of the information. A 
costing scheme for information exchange would enable 
this to occur in a logical manner. 

b. Commercial Satellite 

Commercial satellites provide a potential 
method of handling DDN type information exchange. 
Information would be transmitted using a SNAP to 
transmitter interface as above. This transmitter would 
be separate from those currently used with the NTS. 
Several systems are available for use. 

(1) INMARSAT . The International Maritime 
Satellite Organization (INMARSAT) provides global 
coverage through a system of geostationary satellites 
and should be investigated as a possible transmission 
medium. Costs are decreasing as capability improves. 
INMARSAT is presently used for MLSF ships for message 
communications with satisfactory results. INMARSAT has 
been selected as the communications channel for the 
TRANSEAVER (Transportation by Sea, Verifications) 
system which provides a continual monitoring capability 
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for ensuring the security of nuclear material being 
transported at-sea. This system allows for regular 
communications between ships and land based monitoring 
centers. The computer link is between the ship, the 
land-based INMARSAT shore station, the public switching 
network and the monitoring computers. [Ref. 72] 

(2) VSAT . Another variant in the 
commercial satellite arena is that of the very small 
aperture terminal (VSAT). The VSAT industry is rapidly 
establishing itself in the telecommunications area. 
VSAT provides an excellent means of handling data 
communications networking for businesses. The system 
uses a "star" network with all communications being 
directed through the hub station and then on to 
multiple remote stations. Communications originating 
at remote stations are sent to the hub station which 
can then relay information to other remote stations if 
desired. [Ref. 73] 

VSAT uses C or Ku bands for 
transmission and produce bit error rates of 10 -7 . Data 
rates are available from 9,600 bps to 2,048,000 bps. 
The antenna size is small, usually a 1.8 meter 
reflector. [Ref. 74] The cost of remote terminal sites 
range from $6000 to $12,500. The monthly space segment 
cost for a 56,000 bps network will be approximately 
$1000 to $1200. Commercial vendors estimate cost 
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savings of 20 to 40 percent over their terrestrial 
communication counterparts. [Ref. 75] Present 
commercial coverage is available for the United States, 
Europe, the Mediterranean, Indian Ocean Region, Pacific 
Ocean Region, Atlantic Ocean Region and Caribbean. 
[Ref. 76] 

As an additional note, it is important 
to realize the advantage of this system for crisis 
military operations. The system has great redundancy 
due to the large number of satellites and possesses the 
capability for spread spectrum techniques. Finally, 
should the decision be made to include non-tactical 
data transfer as one of the mission requirements for 
NTS, VSAT technology should be considered as an 
alternative to FLTSATCOM. VSAT can provide improved 
communications capacity and increased survivability at 
low cost. [Ref. 77] 

The capability for data communication 
is presently available commercially and can be added to 
the cost equations in deciding how best to quickly 
transmit needed information. 

c. Physical Delivery 

There will always be times and 
circumstances when electronic transmission of data from 
ships at sea is not possible. The ship may be 
operating under EMCON or MINIMIZE conditions precluding 
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the use of NAVMACS and NTS. Additionally, large 
volumes data with lower priority may reasonably be 
transmitted by physical means. This would include the 
mailing or hand carrying of data tapes or WORM disks. 

A host computer can be configured to 
provide mailbox services for each ship. When the ship 
goes to sea the mailbox becomes the holding point for 
all incoming data. The ship will provide routing 
information in the same method in which mail routing 
information is currently handled. This information 
allows the host computer to forward the accumulated 
data to DDN sites in proximity with the at-sea unit. 
These facilities will make tapes or WORM disks of the 
data and forward them to the ships along with mail, 
personnel or parts deliveries. This is normally 
accomplished via Carrier Onboard Delivery (COD) and 
helicopter flights or replenishment ships. This 
exchange also allows the ship to send outgoing tapes 
for return delivery to the DDN site where the 
information is then transmitted back to the ship’s host 
computer mailbox. [Ref. 78] 

An accounting system is required to ensure 
that information is retained by the sending unit until 
a receipt acknowledgement is obtained. This would 
necessitate large buffer or off-line storage facilities 
both on the ship and at the host computer. This system 
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would handle electronic mail, and more Importantly, 
database and file transfer information including 
MILSTRIP, FAADC obligational reporting, 3-M 
information, and pay and personnel information. 

The host mailbox can function as a 
duplicate ship’s database, containing identical 
information to that in the ship’s SNAP computer. This 
provides the added advantage of being a backup to the 
ship’s system. Currently there is no off ship backup 
for the SNAP system. Fire or flooding could destroy a 
ship’s entire database. The host mailbox and the 
shipboard SNAP computer would be updated whenever 
possible . 

The development of a priority scheme would 
allow the optimum method of transmission to be chosen. 
WORM could be used if it is determined that magnetic 
tapes become a weight and space problem for COD or 
helicopter delivery. The capability of transmitting 
the data from overseas DDN sites would decrease the 
time delays and significantly improve performance. 

5 . Connectivity Costs 

The Space and Naval Warfare System Command 
conducted a review in 1987 to determine the costs of 
providing connectivity between SNAP computers and DDN. 
The review proposed using to NARDAC sites on each coast 
and Naval Telecommunications Centers (NTCCs) overseas 
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to provide the connection to the DDN . The following 
summary of this cost study demonstrates the relative 
low cost necessary to provide connectivity similar to 
interim proposal presented in this section. 

a. Shore Requirements 

Hardware costs include upgrading current 
Honeywell DPS 6/54 computers to DPS 6/75s at NARDAC 
Norfolk and NARDAC San Diego. The costs also include 
providing circuit connection to the DDN from these 
NARDACs and from overseas NTCCs. The total projected 
hardware cost is $425,000. 

Software costs include obtaining DDN 
standard File Transfer Protocol, Simple Mail Transfer 
Protocol and TELNET Terminal Emulation Protocol for one 
time license fees. Annual service costs are estimated 
at $15,000. The total software costs are $105,000. 

Initial integrated logistics support for 
cable connections and training are estimated to be 
$50,000. 

This results in a total cost for the inport 
SNAP data transfer plan to be $580,000. [Ref. 79] 

b. Ship Requirements 

The shipboard hardware costs include the 
purchase of SNAP Intelligent Terminals and their 
supporting equipment. Provisions for one terminal per 
installation for 400 ships would cost $1,800,000. This 
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is a representative cost to allow connection to the DDN 
inport. To complete the connection and provide for 
disk transfer of information from a SNAP connected 
terminal to a NAVMACS connected terminal in Radio 
Central would increase the cost to $5,190,000. 

Software costs to support the shipboard 
installation are estimated at $610,000. This includes 
the software development costs required to execute the 
SNAP to SNAP terminal to NAVMACS terminal to NAVMACS in 
both directions. It also includes the one time 
commercial software cost for emulation and file 
transfer programs. 

Integrated logistic support is estimated at 
$380,000. A total long term cost, to include 
backfitting of terminals on previously installed SNAP 
ships and to provide for direct hardwired connections 
between the two intelligent terminals, is projected at 



$13,490,000. [Ref. 80] 
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VI. CURRENT DEVELOPMENTS 



Currently, there are two programs which have 
actually implemented a SNAP/DDN interface. In each 
case the objective has been to increase speed-of- 
service in transmitting large amounts of data. On the 
ship side, information has initially been entered and 
processed in the SNAP system. This information is 
transmitted via modem to a host computer and then, when 
long haul transmission is required, sent over the DDN 
to its final destination. One system, SDSA , uses the 
NTS to provide data transmission capability while at- 
sea . 

A. SOURCE DATA SYSTEM AFLOAT (SDSA) 

The Source Data System Afloat (SDSA) is a SNAP 
automated disbursing and personnel management system. 
SDSA provides for pay and personnel data entered in the 
SNAP system to be electronically transmitted to and 
received from ashore processing activities. These 
activities are the Naval Finance Center (NFC) for pay 
transactions and Naval Military Personnel Command 
(NMPC) for personnel information. Information -is 
transferred via the NTS while the ship is underway and 
via the DDN while inport. 
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The SNAP systems aboard these two ships are 
configured with a papertape output from the SNAP 
computer which is compatible with the NAVMACS system in 
Radio Central. Data is prepared in the SNAP computer 
and inserted into the NTS without the need for reentry 
into message format. This provides a tremendous 
manpower savings due to the eliminated duplication of 
effort previously required and concurrently eliminates 
potential errors formerly introduced when data was 
being retyped into message format. This method of 
transmission is being used while the ship is at-sea. 

When the ships are inport, information is 
transmitted over the DDN. A SNAP II Intelligent 
Terminal and a 2400 baud Hayes compatible modem provide 
the connection. This allows the ship to interface with 
commercial grade telephone line and connect to a dial- 
up TAC as the entry to the DDN. [Ref. 81] Again, 
additional duplication of data is eliminated and data 
is provided to NFC with same day service. 

This system is currently undergoing Operational 
Evaluation (OPEVAL) aboard USS Fox ( CG 33) and USS 
Trenton ( LPD 14). The Naval Ocean Systems Center 
(NOSC) in San Diego is providing DDN host computer 
services. From NOSC the data is transmitted via DDN 
lines to NFC Cleveland or to NMPC Washington. The 
OPEVAL will serve to certify functional performance of 



69 



SDSA measured in terms of integrity and timeliness. 
"Integrity is defined as the percentage of good records 
received as compared to the total records transmitted. 
Timeliness is defined as an average number of hours to 
complete a given process." [Ref. 82] These results are 
independently examined for both NTS and DDN 
transmission methods. 

Initial data from the USS Fox during the period 
from 21 January to 13 March 1987 demonstrated a NTS 
integrity percentage of 94$ when corrected for initial 
format problems. This pay related information had an 
average processing time of two days. Magnetic tape was 
also forwarded to verify accuracy of data. The regular 
mail forwarding of magnetic tapes had an average 
delivery time of 5.5 days once it was introduced into 
the U. S. Postal System. Ship personnel also stated 
that payroll processing using this system has been 
reduced from days to hours. [Ref. 83] 

The USS Trenton was evaluated during the period of 
1 June to 28 August 1987. This portion of the OPEVAL 
included testing the inport DDN connection and HF 
communications at-sea. DDN integrity, both ship to 
headquarters and headquarters to ship was 100 percent. 
Average total transfer time was 20.5 minutes. The HF 
tests were Inconclusive with only one message being 
sent during the test period. [Ref. 84] Informal 
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correspondence concerning later HF testing shows 
positive results. 

Fleet impact is elucidated by several comments made 
from a SDSA status report made by the USS Fox during 
her recent deployment. 

Data transmission is the intended strong point of 
SDSA. Events may now be transmitted and posted in 
a one day turnaround for a deployed unit. This is 
a dramatic improvement. 

SDSA has all but eliminated the large consumption 
of time and effort required for the preparation and 
submission of OCR documents. 

SDSA will keep pay accounts current and eliminate 
long delays between entitlements and their 
liquidation. Sailors will be able to understand 
their pay better and provide intelligent feedback 
to the Disbursing Office. [Ref. 85] 

An additional function of the OPEVAL is to examine 
the ability of SDSA to reduce existing message traffic 
volume over the NTS. This will be accomplished by 
comparing all pay and personnel message traffic of the 
SDSA test ships to that of two non-test ships, the USS 
Bunker Hill (CG 52) and the USS Duluth (LPD 6). An 
analysis of the traffic volumes of the ships being 
monitored will provide important information on the 
expected impact that fleet-wide implementation of SDSA 
would have on the NTS. An initial report is due 31 
March 1988. 

While the OPEVAL is still on-going, the initial 
results indicate that this will become a successful 
program. The benefits of ease in processing, reduction 
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of errors and improved transmission time are achieved 
with minimal dollar costs and impact on existing 
systems. Advantages gained by the DDN interface appear 
to be substantiated and should be continued. The 
results of the NTS traffic analysis study will be most 
interesting and merit close attention. This may 
provide the single most important factor in the 
determination of the viability of this system for at- 
sea use. 



B . WATERFRONT MAINTENANCE MANAGEMENT SYSTEM (WMMS) 

The Waterfront Maintenance Management System (WMMS) 

was established by the Commander Naval Surface Force, 

U. S. Pacific Fleet ( COMNAVSURFPAC ) in response to the 

need for improving fleet maintenance and logistic 

support. WMMS serves as a management aid in 

efficiently coordinating shipboard maintenance thereby 

ensuring that materially ready ships are available for 

the Fleet Commander. [Ref. 86] 

(Ship's) required maintenance is programmed through 
the 3M system in each units Coordinated Ships 
Maintenance Project ( CSMP ) . Specific work items 
from each units CSMP are organized into Work 
Packages, the work is scheduled and accomplished at 
Repair Activities, and the labor and monetary costs 
of the work then reported to a central Navy data 
base at Navy Maintenance Support Office ( NAMSO ) . 
This process is highly dynamic due to changing 
"customer" ship schedules ... WMMS has provided 
automation of this data base and communication of 
work packages to provide maintenance to the Pacific 
Fleet and thereby ensure Fleet Readiness. [Ref. 87] 
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The primary objective of WMMS is to maximize the 
effectiveness and efficiency of maintenance dollars 
through the improved maintenance management provided by 
the system’s decision support and communications 
capabilities. The use of a near real-time database and 
supporting telecommunications capability is essential 
in effectively meeting the ever changing needs of the 
Surface Force. Maintenance management demands that 
large amounts of detailed information be transmitted to 
appropriate logistic and maintenance activities as 
quickly as possible. Ship’s schedules compound this 
problem by adding an ever changing geographic variable. 
[Ref. 88] 

The enemy of the maintenance problem is time. 
Ships have operational commitments and maintenance 
availability is accommodated within these time 
constraints. Lost time due to communications and 
processing delays shorten parts procurement lead times. 
Parts expediting, required to meet operational 
commitments, is expensive. Additionally, emergent work 
requests for mission essential repairs requires that 
accurate information be quickly transmitted to allow 
specifications to be validated, parts procured, and 
when necessary, repair teams established and 
transported to the appropriate location. Finally, when 
commercial industrial support (CIS) services are 
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required, the timeliness in which accurate and complete 
information is provided directly impacts the quality of 
work as well as the total cost. 

WMMS provides shore based computers the ability to 
store and process required information. During fiscal 
years 1986 and 1987 this system was converted for 
operation on Digital Equipment Corporation (DEC) VAX 
series mini and microcomputers. This computer system 
is centered at COMNAVSURFPAC in San Diego. This master 
site has clustered DEC 8530 and 8250 minicomputers. 
Other sites include Pearl Harbor, Subic Bay, San 
Francisco, Yokosuka and Guam. This system is 
programmed in basic and has the following software 
modules: Current Ship’s Maintenance Project, Work 
Package Tracking, Boiler/Diesel Inspection Tracking, 
Casrep Tracking, CIS Fund Tracking, Departure from 
Specifications Tracking, Ship Alteration Packages, and 
Industrial Plant Equipment Tracking. [Ref. 89] 

WMMS requires an efficient telecommunications 
capability to become useful and this is provided by the 
DDN which allows: 

User capable CSMP file transfer between sites, and 
user groups at sites, in fully automated form 
without technical assistance. 

Use of electronic messaging systems between site 
users using MILNET or other DDN networks. 

Provisions for high speed data connections to site 
area DDN Hosts. 



74 



Internet connections and usage via DDN 
[Ref. 90] 



access . 



WMMS hosts use the Wollongong Group’s WIN/VX 
package to provide the required DDN protocols. 

WMMS is currently scheduled to evolve into the 
Maintenance Resource Management System (MRMS). The MRMS 
will combine and supersede existing Type Commander 
systems, developing into a standardized, SNAP 
compatible system for both the Atlantic and Pacific 
Fleets. Like WMMS, the MRMS will support Fleet and 
Type Commander maintenance staffs, Readiness Support 
Groups (RSGs), Intermediate Unit Commanders (IUCs), 
Intermediate Maintenance Activities ( IMAs ) , and Ship 
Repair Facilities (SRFs). The standardized automated 
information system provided by MRMS is expected to 
significantly contribute to improvements in personnel 
productivity and material condition throughout the 
Fleet. This will be attained through "efficient 
allocation of maintenance resources, reduction in 
paperwork, and improved flow of information between key 
activities in the maintenance management process." 
[Ref. 91] 



SUMMARY 



The significance of WMMS and SDSA is that they 
demonstrate the Navy’s perceived need for increased 
information flow. Each has independently accomplished 
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the same goal of connecting shipboard SNAP systems to 
shore based computers by using the DDN . The DDN 
functions as the transmission medium for both ship-to- 
shore-to-ship and host-to-host information exchange. 
These successful systems portend the future where this 
capability will be expanded to include all of the ships 
information exchange requirements. 

These programs represent the beginning of a new era 
in data exchange. It is important that a continued 
effort is maintained for development and expansion. In 
both cases the programs are evolutionary requiring 
constant feedback and review. Efforts must be made to 
ensure that the costs and benefits of these programs 
become available to the operational commanders. Proper 
evaluation of these programs will allow intelligent 
decisions to be made concerning their viability and the 
cost effectiveness of more inclusive programs using 
this technology. 
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VII. ANALYSIS 



The most appropriate method of examining the 
potential value which a SNAP/DDN interface could 
provide is to review similar systems currently in 
existence. Any attempt to assign dollar values to the 
applications provided by the DDN would be mere 
speculation at this point. Even when considering SDSA 
and WMMS , the youth of these programs precludes 
sufficient data to determine actual dollar values. The 
number of major companies presently using computer 
systems with telecommunications capabilities similar to 
those provided by DDN are rapidly rising. The 
following discussion presents the impact that these 
systems have had on selected companies. 



A. DDN APPLICATIONS 

1 . Electronic Mail 

During the 1970’s private industry began using 
various forms of electronic mail. Most of these 
systems were internal in nature and often used in 
multinational companies. Response in the commercial 
sector has been positive and it is expected that 



electronic 


mail will 


become a 


common 


form of 


inf ormation 


exchange in 


the future. 


much 


like mail 


today . 


The following 


industrial 


systems 


provide 
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examples of applications similar to those required for 
use by the Navy. 

a. Texas Instruments 

Texas Instruments began using electronic 
mail in 1977. Electronic mail was rapidly accepted as 
demonstrated by the trends in the number of 

transactions. These numbers have increased from 10,000 
per day in 1977 to 25,000 per day in 1979. Costs have 
decreased from eight cents to four cents per message 
during this same period. TI views this increase as 
positive and beneficial to the company despite of the 
overall expense of the system. They believe that 
increased speed-of-service , reduction of copying and 
messengering time, and better privacy of communications 
makes electronic mail cost effective with direct 
productivity increases. Company studies provided 
statistics demonstrating overall productivity increases 
for managers and administrators of 13 percent and 20 
percent increases for secretarial/clerical personnel. 
These results suggest that the savings from 

productivity increases are of significant magnitude to 
recover system development costs in three years. 
[Ref. 92] 

b. Volvo 

Volvo implemented a private electronic mail 
system in 1980, connecting the company’s management 
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throughout the world in 1983. In 1986 they had over 
350,000 transactions dally. This represents a steady 
growth rate since 1980. Volvo research has shown that 
"...in the business world, four out of five phone calls 
fail to reach the intended party on the first try. 
Internal mail correspondence at Volvo averages two to 
two-and-a-hal f days as opposed to Memo (electronic 
mail), which is immediate." [Ref. 93] This is 
compounded with the difficulties of time differences 
that a world wide organization must content with when 
voice communications are used. Volvo studies show that 
their use of electronic mail increases productivity 
about five percent in addition to making communications 
easier for their personnel. [Ref. 94] 

c. Digital Equipment Corporation 

Digital Equipment Corporation initiated 
their electronic mail system in 1977. It was done to 
minimize the lost time between engineers when they 
attempted to contact each other. The system was 
rapidly developed and expanded. Digital conducted a 
cost Justification study to determine the economic 
impact of electronic mail. The study compared the cost 
of electronic mail versus the costs incurred by methods 
of communication which would have been used in lieu of 
electronic mail. The study revealed a bottom line 
figure of thirty percent savings using electronic mail 
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over more conventional communications methods. This 
figure increases as the number of recipients per 
message increases. Additionally, Digital felt that 

there were many intangible factors not taken into 
account which makes electronic mail even more 
advantageous. [Ref. 95] 

d. Electronic Mail Assessment 

Electronic mail provides an excellent 
method for rapid communication. It affects 

organizations in the following ways. First, it 

provides the potential to improve subformal 
communication within the organization. This can 

directly improve organizational effectiveness. 
Second, it can transmit information instantly, at low 
cost. Systems are now available which can transmit 
messages throughout the world crossing between private 
and public networks with a typical cost of twenty cents 
[Ref. 96]. Third, it can improve organization 

efficiency. A study by the Navy Personnel Research and 
Development Center revealed that officers felt that 
electronic mail reduced both the number of memos sent 
and the number of meetings held [Ref. 97]. The overall 
conclusion is that electronic mail is a great benefit 
to an organization and is a wise investment. 
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File Transfer Protocol 



2 . 

An equivalent commercial application of file 

transfer protocol is demonstrated by a technique called 

electronic data interchange (EDI). This technique is 

being used by companies including Wal-Mart and J. C. 

Penney Co. to transmit formatted documents between 

different company’s computers. 

It lets companies use fewer data-entry employees, 
thus eliminating human error and avoiding delays of 
days or weeks. It can lower inventory levels, 

eliminate lost invoices, and improve customer 
service, since customers can respond faster to 
customer needs. [Ref. 98] 

While using this system at Wal-Mart, specific savings 
were observed including, a fifty percent reduction in 
delivery time and a 31 percent sales increase. This 
was attributed to the more responsive stocking of 
product lines facilitated by EDI. J. C. Penney Co. saw 
a 59 percent sales increase in its Stafford brand 
suits, again attributed to the quick turnaround and 
ability to immediately adjust to the customer's 

demands. [Ref. 99] 

The ability to quickly transmit data between 
locations is directly related to costs. The above 
examples demonstrate the type of cost saving possible. 
Significant saving are also expected in Navy 



applications. In addition 
also intangible benefits 
capability. These include 
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to cost savings, there are 
derived from this type of 
the reduction of paperwork 



and improved performance gained through the ability to 
rapidly share instructions, directives and programs. 

The addition of TELNET to FTP provides the 
capability to actually enter another command’s 
database. This allows requesting commands access to 
information without imposing additional administrative 
demands on fleet units. 

It is important to consider two factors when 
evaluating electronic information exchange. First, 
there is a synergistic effect which occurs in this area 
of electronic automation. As the number and variety of 
applications increase, the overall benefits of such 
systems multiply at a faster rate. Specifically, the 
more capable the system is as a whole, the more 
efficient the utilization of the system. Second, the 
value of electronic information exchange to a specific 
organization increases as the number of users increase. 
The analogy here is that of the telephone. The true 
value of the telephone system was realized once the 
entire country was interconnected. These factors hold 
true in the evaluation of the Navy’s systems. A 
capable system which is interconnected with a large 
number of like users provides maximum benefits. 

B. CONNECTIVITY 

As discussed in previous chapters, the difficulty 
of connectivity is the most significant problem to 
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overcome in establishing a workable SNAP/DDN interface. 
Costs are relatively inexpensive to provide ship to DDN 
connections for ships inport. At-sea connectivity is 
an entirely different matter however. The most readily 
available and inexpensive approach to accommodate 
information exchange for ships at-sea is to implement 
an efficient system for physical transfer of tapes and 
WORM disks as described in Chapter V. This improves 
the speed-of-service and has no adverse impact upon the 
NTS. Long range solutions should include the 
possibility of increasing satellite capability, both 
Navy and commercial. Until the utilization of the 
limited bandwidth of the NTS is improved, the NTS will 
simply not be able to provide the desired quantity of 
administrative data. 



C. PEOPLE PROBLEMS 

During the author’s review of the SNAP system, it 
became obvious that significant problems exist in the 
fleet concerning the use and understanding of the 
system’s capabilities. These problems must be 
addressed before the true benefits of a SNAP/DDN 
interface can be realized. A large number of problems 
can be discussed by examining the two areas of 
education and training. 
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1 • Education (Understanding of capabilities) 



Education is that area concerned with the 
understanding of the system’s capabilities. This needs 
to be addressed during the instruction of personnel who 
are dependent upon data maintained by the SNAP system. 
This includes commanding officers, executive officers, 
department heads and division officers. A managerial 
approach to using the SNAP system as a method to more 
effectively perform in supervisory positions must be 
presented. The system will not function effectively if 
active involvement from the top does not occur. 
Supervisory personnel must be taught the potential of 
the system as a management tool . An understanding of 
the query system for ad hoc requests is necessary. 
These personnel should know the kinds of information 
available through SNAP and that additional requirements 
can be obtained by own ship programming or through 
requests submitted up the chain of command. 

Active involvement will be required to ensure 
that officers become aware of the services available 
through the DDN. Only through their support and effort 
will the system become effective. 

2 . Training 

Training deals with the actual operation of the 
system. It goes hand in hand with education. User 
personnel at all levels must be provided hands on 
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training. This training should provide sufficient time 
for the users to fully acquaint themselves with the 
system. Currently this is not occurring. Formal 
training is non-existent for work center personnel and 
there are no plans to provide this training in the 
future [Ref. 100]. This is viewed as a significant 
shortfall by the surface type commander’s ADP officers 
on both coasts. [Refs. 101,102] Discussions with 
recent graduates of Surface Warfare Officer Department 
Head School also indicated that they felt the training 
was inadequate. 

Until a concerted effort is mounted to both 
educate and train officer and enlisted personnel, SNAP 
will not be used to its true capabilities. The 
administrative burden that SNAP was created to reduce 
will not be improved. To effectively implement a 
SNAP/DDN interface, proper training and education are 
essential. Personnel must appreciate and understand 
the capabilites of SNAP and combine that knowledge with 
that of the DDN. This instruction is as important as 
the hardware itself. The Navy must direct sufficient 
resources to this area to obtain the benefits that the 
system is capable of providing. 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The results of this study indicate that the 
additional services provided by a SNAP/DDN interface 
would be most beneficial to the United States Navy. 
The immediate value of DDN pier connections is the 
relief that would be provided to the NTS by serving as 
an alternate means for electronic communication. Even 
a message reduction of ten percent, gained by this 
connection, would buy years of additional time to 
implement long term information exchange solutions. 

An equally significant result of this connection is 
the improvements to organizational efficiency which it 
can provide. The improvements of informal 
communications and the resultant increase in 
organizational slack are significant. Paper reductions 
gained from improved methods of maintaining and 
transmitting required information would be extremely 
valuable. This could reduce the administrative effort 
required of shipboard personnel by eliminating the 
necessity for paper-prepared reports and the time 
devoted to shipping and receiving them. The reduction 
of the paper itself is beneficial from storage, ship’s 
endurance, and damage control perspectives. The fact 
that most information will be maintained in the SNAP 
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standardization 



of administrative 



system creates 
processes between the fleets. The ability of shore 

commands to extract information from ship’s systems 
effectively acts to shift a portion of the 

administrative load ashore. 

Direct electronic at-sea connectivity is available 
in the near term only through the NTS. This provides a 
valuable capability for ships which can be exploited 
when necessary. It is essential, however, that the 
Navy rapidly develop alternate means of handling high 
volume information exchange at-sea. WORM provides a 
cheap, light weight, small volume medium for 
transferring data ashore. Information thus provided to 
DDN capable commands can greatly Improve upon current 
speed-of-service . Host computers providing mailbox 
services complete the loop. Commercial satellites 
could also provide a cheap and readily available method 
for transmitting this information ashore. 

B. RECOMMENDATIONS 

The shore portion of the SNAP/DDN interface should 
be Implemented at the earliest possible time. 
Improvements to our capabilities at-sea require 
Immediate consideration. 

A training plan must be developed and implemented 
at the time of the connection. This plan must contain 
provisions for ongoing training with emphasis on 
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Mobile training teams with 



off-ship training, 
classroom capability need to be established. This 
program must include the education of management 
applications in addition to simply providing operator 
level instruction. 

The development of costing data for the various 
types of information exchange is a necessity. Armed 
with accurate information on the actual costs for 
different methods of information transfer, intelligent 
decisions can be made on the value of these 

capabilities. When combined with the forthcoming data 
from WMMS and SDSA , investigators will be able to 
assign weights to the time value of information. This 
allows for determining the optimum mix of the different 
technologies. Expert systems could then be designed to 
act as a filter to route information from the ship to 
the required destination in the most cost effective 
manner . 

The most important recommendation is that 
continuing studies of the pilot programs must be 
maintained. The results of these studies need to be 
promulgated to the senior operational warfare 
commanders. It is these operational commanders who 

must become involved with the process of determining 
the correct mix of telecommunications capabilities. 
The Navy can ill afford to continue to have support 
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communities dictate the limits of the Navy’s 
information capacity. The warfare communities must 
make those decisions by determining their requirements 
and evaluating them concurrently with ships, planes and 
weapon systems. 
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APPENDIX 





GLOSSARY OF ACRONYMS 


ADCA 


Afloat Data Communications 

Architecture 


ADP 

ADM 

ARPANET 

ASC 

AUTODIN 


Automated Data Processing 

Administrative Data Management Subsystem 
Advanced Research Projects Agency Network 
Automatic Switching Center 
Automatic Digital Information Network 


BITS 

BPS 


Base Information Transfer System 
Bits Per Second 


CDA 

CD-ROM 

CIS 

CNO 

COD 

COMNAVSURFPAC 


Central Design Activity 
Compact Disk - Read Only Memory 
Commercial Industrial Support 
Chief of Naval Operations 
Carrier Onboard Delivery 

Commander Naval Surface Force, U.S. 

Pacific Fleet 


COMNAVTELCOM 


Commander Naval Telecommunications 

Command 


COSAL 

CSMP 

CUDIX 


Consolidated Ships Allowance Listing 
Current Ship’s Maintenance Project 
Common User Digital Information Exchange 


DAMA 

DARPA 

DCA 

DCS 

DDN 

DOD 

DSN 


Demand Assigned Multiple Access 

Defense Advanced Research Projects Agency 

Defense Communications Agency 

Defense Communications System 

Defense Data Network 

Department of Defense 

Defense Switched Network 


EMCON 


Emission Control 


FAADC 

FLTCINC 

FLTSATCOM 

FSB 

FTP 


Fleet Accounting and Disbursing Center 
Fleet Commander in Chief 

Fleet Satellite Communications Satellite 
Fleet Satellite Broadcast 
File Transfer Protocol 


HF 


High Frequency 


IDS 

IUC 

IMA 


Integrated Data Services 
Intermediate Unit Commander 
Intermediate Maintenance Activity 
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INMARSAT 

IP 

I S/A AMPE 

ISDN 

LEASAT 

LHDAC 



MDS 

MILNET 

MILSTRIP 

MLSF 
MR MS 

NAMSO 

NARDAC 

NAVCAMS 

NAVCOMPARS 

NAVCOMMSTA 

NAVDAC 

NAVGRAM 

NAVMACS 

NAVMASSO 

NDCCA 

NFC 

NMPC 

NOSC 

NTC 

NTCC 

NTS 

NWP 

OAN 

OCR 

OPEVAL 

OPTAR 

OTCIXS 



PABX 

PSN 

RSG 



International Maritime Satellite 

Organization 

Internet Protocol 

Inter Service/Agency Automated Message 
Processing Exchange 

Integrated Services Digital Network 
Leased Satellite 

Long Haul Data Communications 

Architecture 

Maintenance Data Subsystem 
Military Network 

Military Standard Requisitioning and 
Issue Procedures 
Mobile Logistics Ship Force 
Maintenance Resource Management System 

Navy Maintenance Support Office 
Navy Regional Data Automation Center 
Naval Communications Area Master Station 
Naval Communications Processing and 
Routing System 

Naval Communications Station 

Navy Data Automation Command 

Navy Mailed Message Program 

Naval Modular Automated Communications 

Subsystem 

Navy Management Systems Support Office 

Navy Data Communications Control 

Architecture 

Naval Finance Center 

Naval Military Personnel Command 

Naval Ocean Systems Center 

Naval Telecommunications Command 

Naval Telecommunications Center 

Naval Telecommunications System 

Naval Warfare Publication 

Office Automation Network 
Optical Character Reader 
Operational Evaluation 
Operating Target 

Officer in Tactical Command Information 
Exchange System 

Private Automatic Branch Exchange 
Packet Switching Node 

Readiness Support Group 
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SDSA 

SECNAV 

SFM 

SIMA 

SMPT 

SMS 

SNAP 

SSIC 

SSIXS 

SRF 


Source Data System 
Source Data System Afloat 
Secretary of the Navy 

Supply & Financial Management Subsystem 
Shore Intermediate Maintenance Activity 
Simple Mail Transfer Protocol 
System Management Subsystem 
Shipboard Non-tactical ADP Program 
Standard Subject Identification Code 
Submarine Satellite Information Exchange 
System 

Ship Repair Facility 


TAC 

TACINTEL 

TADIXS 

TCP 

TELNET 

TRANSEAVER 


Terminal Access Controller 
Tactical Intelligence Subsystem 
Tactical Data Information Exchange System 
Transmission Control Protocol 
Terminal Network Protocol 
Transportation by Sea, Verification 


UHF 


Ultra High Frequency 


VSAT 


Very Small Aperture Terminal 


WHO IS 

WMMS 

WORM 


A DDN user directory 

Waterfront Maintenance Management System 
Write Once, Read Many 


3-M 


Material Maintenance Management Program 
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